Published on LinkedIn June 1, 2026
When a delivery program struggles, the first conversation is almost always about the delivery team. Timelines slipping, quality dropping, capacity stretched. The team is visible, the symptoms are visible, and the connection between the two feels straightforward. It is also usually wrong.
Delivery failure is rarely a delivery problem. It is an upstream problem that becomes visible in delivery.
The work that reaches a delivery team arrives carrying the decisions, gaps, and ambiguities that existed before the team ever touched it. When intake is unclear, the delivery team inherits the confusion. When prioritization is missing, the delivery team absorbs the conflict. When decision-making authority is undefined, the delivery team waits. The symptoms appear in delivery because that is where the work becomes concrete and visible. The causes exist upstream, in the systems and structures that govern how work enters and moves through the organization before delivery begins.
Examining the delivery team first is the most expensive diagnostic error organizations make. It consumes time, creates friction with capable people, and leaves the upstream architecture entirely intact. The next program runs into the same problems because nothing that actually caused the failure was examined or changed.
W. Edwards Deming spent decades making a version of this argument. In The New Economics for Industry, Government, Education, published in 1993, he introduced the System of Profound Knowledge and formalized what became known as the 94/6 Rule. His position, grounded in decades of organizational research, was that 94 percent of failures originate in the system rather than in the individuals working within it. When something goes wrong, the instinct is to find the person responsible. Deming’s research pointed consistently to the design of the system upstream of where the failure became visible.
The delivery environment is where that principle is most consistently ignored.
The upstream architecture that determines delivery outcomes operates across three areas. The first is intake. How work enters the delivery system determines almost everything that follows. When intake criteria are vague, when requests arrive without clear outcomes defined, or when volume is accepted without reference to capacity, the delivery team begins every program in a deficit. They are resolving ambiguity that should have been resolved before the work was approved. That resolution work is invisible in most reporting systems, which means it is also invisible to the leaders making intake decisions.
The second is prioritization. In most delivery environments, prioritization is either absent or performed at the wrong level. Everything is marked urgent. Everything is marked high priority. The delivery team receives a portfolio of work in which the relative importance of each initiative is undefined or contested, and they are expected to sequence and deliver it without decision-making authority to resolve the conflict. The prioritization problem belongs to leadership. The consequence lands in delivery.
The third is the decision-making structure. Delivery programs require decisions continuously. Scope questions, resource questions, dependency questions, risk questions. When the decision-making architecture upstream of the delivery team is unclear, slow, or inaccessible, programs stall at every point where a decision is required. The delivery team is accountable for the timeline. The decisions controlling that timeline sit elsewhere. That gap is where delivery credibility erodes most consistently and most unfairly.
I have watched capable delivery leaders absorb accountability for failures they did not create. Programs that were approved without defined outcomes, prioritized without reference to capacity, and handed to delivery teams without the decision authority required to manage them. The delivery team works harder to compensate. The timeline still slips. The post-mortem examines delivery execution. The upstream architecture is never part of the conversation.
That pattern is not a delivery problem. It is a system design problem that Deming would have recognized immediately.
The organizations that break this pattern treat upstream design as a prerequisite for delivery. Before a program enters delivery, three questions need to be answered clearly. What is the defined outcome this work is supposed to produce? What is its priority relative to everything else currently in delivery? And who holds the decision authority required to unblock the program when it encounters the obstacles every program encounters?
When those questions are answered before delivery begins, the delivery team can do the work they were hired to do. When they are not, the delivery team spends a significant portion of their capacity doing work that was never theirs to carry.
Fixing delivery without examining upstream design is not a solution. It is a more expensive version of the same outcome. The delivery team changes. The intake process does not. The prioritization problem does not. The decision-making gaps do not. The next program hits the same structural constraints, and the diagnosis returns to the delivery team because that is where the symptoms are visible.
Deming’s 94/6 Rule is not a comfortable number for most organizations. It requires leaders to examine the systems they designed and operate rather than the people working within them. In delivery environments specifically, it requires an honest audit of what arrives at the delivery team’s door and whether the upstream architecture that produced it was built to support delivery success or simply to move work downstream as quickly as possible.
Those are not the same thing. Most organizations have not examined which one they have built.
Strategic Signals publishes monthly on strategy systems and execution clarity for senior leaders. Subscribe to receive each issue directly. Subscribe
